<html>
<head><meta charset="utf-8"><title>testing type inference · t-compiler/rust-analyzer · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/index.html">t-compiler/rust-analyzer</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html">testing type inference</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="163314723"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163314723" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163314723">(Apr 14 2019 at 12:17)</a>:</h4>
<p>I've been thinking how to write more focused type checking tests (where just one or a few specific expressions are being tested). One thing I'd like to do is validate them against rustc, i.e. make sure that rustc infers the same type for that expression. I'm currently considering two ways:<br>
1. a macro that defines a test: The end result would maybe look somewhat like this:</p>
<div class="codehilite"><pre><span></span><span class="n">ty_test</span><span class="o">!</span><span class="p">(</span><span class="n">method_resolution_trait_before_autoderef</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">trait</span><span class="w"> </span><span class="n">Trait</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">u128</span><span class="p">;</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="w">    </span><span class="k">struct</span> <span class="nc">S</span><span class="p">;</span><span class="w"></span>
<span class="w">    </span><span class="k">impl</span><span class="w"> </span><span class="n">S</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="o">&amp;</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="kt">i8</span> <span class="p">{</span><span class="w"> </span><span class="mi">0</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="w">    </span><span class="k">impl</span><span class="w"> </span><span class="n">Trait</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">S</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">u128</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="mi">0</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="w">    </span><span class="n">assert_type</span><span class="o">!</span><span class="p">(</span><span class="n">S</span><span class="p">.</span><span class="n">foo</span><span class="p">(),</span><span class="w"> </span><span class="n">u128</span><span class="p">)</span><span class="w"></span>
<span class="p">});</span><span class="w"></span>
</pre></div>


<p>and it would on the one hand include that code in the actual test (with <code>assert_type</code> expanding to something that fails to build if the type doesn't match), and on the other hand use <code>stringify</code> to generate a test that runs RA's type inference on the code and checks that the asserted type is correct (with a different definition of <code>assert_type</code>).<br>
2. use <code>compiletest</code> and test via diagnostics: We'd need to first add diagnostics for type checking errors (maybe toggleable somehow), and then we'd implement enough of <code>compiletest</code> to compare RA's diagnostics to the ones defined in the test file, so something like</p>
<div class="codehilite"><pre><span></span><span class="k">trait</span><span class="w"> </span><span class="n">Trait</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">u128</span><span class="p">;</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="k">struct</span> <span class="nc">S</span><span class="p">;</span><span class="w"></span>
<span class="k">impl</span><span class="w"> </span><span class="n">S</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="o">&amp;</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="kt">i8</span> <span class="p">{</span><span class="w"> </span><span class="mi">0</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="k">impl</span><span class="w"> </span><span class="n">Trait</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">S</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">fn</span> <span class="nf">foo</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span><span class="w"> </span>-&gt; <span class="nc">u128</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="mi">0</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="k">fn</span> <span class="nf">test</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="kt">i8</span> <span class="p">{</span><span class="w"> </span><span class="n">S</span><span class="p">.</span><span class="n">foo</span><span class="p">()</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="c1">// ~ERROR mismatched types</span>
</pre></div>


<p>The nice thing about this would be that it could be used for other diagnostics as well, but the error annotations in the compiletest files would have to be written to match both rustc's and RA's diagnostics, which would probably be complicated. Also it'd make the tests somewhat dependent on rustc's error messages.</p>
<p>What do you think?</p>



<a name="163316951"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163316951" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163316951">(Apr 14 2019 at 13:23)</a>:</h4>
<p>Good questions!</p>
<p>Having focused unit-test would be really helpful. Long run, I imagine having our own well-factored test-suite  will be better than direct comparison with rustc (especially if we are aiming at merging with rustc typchecker: it would be a shame if sharing type-checking code makes all the tests void :D ). I also feel like we shouldn't rely on <code>compiletest</code>, at lest directly: there's going to be a <strong>huge</strong> number of tests, and any communication with compiler is bound to make them slower. So, I'd game for something like <code>insta</code>, but where the <em>gold</em> values to compare against could be generated by using rustc, once. </p>
<p>If we are going to have astronomical number of tests here, than maybe going full-data would be beneficial? Basically, using the same setup we use for parsing --- a <code>.data</code> folder with cases and gold results.</p>



<a name="163317155"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317155" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317155">(Apr 14 2019 at 13:29)</a>:</h4>
<p>Do we actually get a big long-term value out of validation with rustc? </p>
<p>I imagine the value here is "we can confidently replace typechecker in the compiler", but I imagine we could write comparison test when actually switching the typecher (and even than, I'd imagine we'd just run both typechecker simultaneously for some time to check the results on real code).</p>
<p>For "making sure that type-checker works mostly correct", I feel like just writing test by hand will be faster.</p>
<p>What would help is a <em>minimal</em> corpus of rust code that exercises type-checker in an interesting way. I think reusing IntelliJ test-suite  would be a smart move here, it should be pretty well factored</p>



<a name="163317270"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317270" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317270">(Apr 14 2019 at 13:32)</a>:</h4>
<p>My goal isn't to directly compare to rustc, but rather to make sure that the 'gold' value is the same as in rustc (or in other words, to be able to run the same test against rustc's type checker)</p>



<a name="163317278"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317278" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317278">(Apr 14 2019 at 13:32)</a>:</h4>
<p>Hm, actually, I think there could be a <strong>huge</strong> value in the compiler-independent rust-typecheker test suite!</p>



<a name="163317290"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317290" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317290">(Apr 14 2019 at 13:33)</a>:</h4>
<p>so e.g. in the first example, the test defines what type is expected, but it's written in a way that it wouldn't even compile if the expected type is not the same one as rustc would infer</p>



<a name="163317343"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317343" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317343">(Apr 14 2019 at 13:34)</a>:</h4>
<p>as a way to 'prove' that the expectation is actually correct ;) (since e.g. I didn't know beforehand in which order autoderefs happen vs. looking at extension methods)</p>



<a name="163317375"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317375" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317375">(Apr 14 2019 at 13:35)</a>:</h4>
<p>Yeah, I see how this could be useful in various corner cases. OTOH, for, for example, autoderef one can write a test-case manually and see. That is, such cases seems pretty rare to me</p>



<a name="163317498"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317498" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317498">(Apr 14 2019 at 13:38)</a>:</h4>
<p>coming back to the idea of the compiler-independent test-suite: let's say that a test is a rust-file (possibly with special mark-up, like <code>&lt;|&gt;</code> thing),  and the result of the test is a human-readable representation of the type.</p>
<p>We than have a "driver" which feeds this into rust-analyzer, and a driver which feeds it into <code>rustc</code>. </p>
<p>By not depending on precise diagnostics, this should actually be feasible to implement</p>



<a name="163317502"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317502" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317502">(Apr 14 2019 at 13:38)</a>:</h4>
<p>I guess we can invent something for non-denotable types like closures?</p>



<a name="163317520"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317520" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317520">(Apr 14 2019 at 13:39)</a>:</h4>
<p>The benefit I see in this setup is that the test-suite is 100% text files, so it could be reused by other projects with minimal effort</p>



<a name="163317561"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317561" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317561">(Apr 14 2019 at 13:40)</a>:</h4>
<p>I imagine it will be possible to always write tests without having to denote non-denotable types</p>



<a name="163317589"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317589" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317589">(Apr 14 2019 at 13:41)</a>:</h4>
<p>(another reason is btw that I'm always annoyed that I'm writing rust code inside a string inside rust code, without any editor support ;) )</p>



<a name="163317642"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317642" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317642">(Apr 14 2019 at 13:42)</a>:</h4>
<p>the tests could use an attribute like <code>#[expected_type(i128)]</code>, we'd just have to turn that into tests compileable with rustc as well</p>



<a name="163317660"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317660" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317660">(Apr 14 2019 at 13:43)</a>:</h4>
<p>cool! Yeah, a "special" mark-up could be a magic macro call!</p>
<p>And it could expand to <code>let _: $ty = $expr;</code> in rustc</p>



<a name="163317662"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317662" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317662">(Apr 14 2019 at 13:43)</a>:</h4>
<p>LIke, <code>expect_ty!(2 + 90, i32)</code></p>



<a name="163317714"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317714" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317714">(Apr 14 2019 at 13:44)</a>:</h4>
<p>with which we're almost at my option 1 ;)</p>



<a name="163317719"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317719" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317719">(Apr 14 2019 at 13:45)</a>:</h4>
<p>except with separate files</p>



<a name="163317812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317812">(Apr 14 2019 at 13:47)</a>:</h4>
<p>Yeah.... I feel like option 1 wouldn't work for <strong>all</strong> of the cases. Specifically, I think we might want to specify lang-items inside the tests</p>



<a name="163317877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163317877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163317877">(Apr 14 2019 at 13:48)</a>:</h4>
<p>There's also a tradeoff:</p>
<p>inline test data, like in macro or in a string literal, is easier to work with</p>
<p>out-of-line data in the directory is easier to reuse in some yet-unknown projects</p>



<a name="163318122"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163318122" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163318122">(Apr 14 2019 at 13:55)</a>:</h4>
<p>yeah</p>



<a name="163318176"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163318176" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Florian Diebold <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163318176">(Apr 14 2019 at 13:56)</a>:</h4>
<p>I'll write the test in the straight-forward way for now anyway, we need a bit better macro support before we can do this :)</p>



<a name="163318730"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163318730" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163318730">(Apr 14 2019 at 14:10)</a>:</h4>
<p>FWIW, long-term, specifying tests in strings should give use more editor support than specifying them in macros</p>



<a name="163318732"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163318732" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163318732">(Apr 14 2019 at 14:10)</a>:</h4>
<p><a href="/user_uploads/4715/hBTRYQ3RDOWqTevNjCmRdlUI/pasted_image.png" target="_blank" title="pasted_image.png">pasted image</a></p>
<div class="message_inline_image"><a href="/user_uploads/4715/hBTRYQ3RDOWqTevNjCmRdlUI/pasted_image.png" target="_blank" title="pasted image"><img src="/user_uploads/4715/hBTRYQ3RDOWqTevNjCmRdlUI/pasted_image.png"></a></div>



<a name="163318756"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/185405-t-compiler/rust-analyzer/topic/testing%20type%20inference/near/163318756" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/185405-t-compiler/rust-analyzer/topic/testing.20type.20inference.html#163318756">(Apr 14 2019 at 14:11)</a>:</h4>
<p>though I am not sure how this whole "Language Injection" workflow should work in the LSP setting...</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>